As the value and use of information continues to increase, individuals and businesses seek additional ways to process and store information. One option available to users is information handling systems. An information handling system generally processes, compiles, stores, and/or communicates information or data for business, personal, or other purposes thereby allowing users to take advantage of the value of the information. Because technology and information handling needs and requirements vary between different users or applications, information handling systems may also vary regarding what information is handled, how the information is handled, how much information is processed, stored, or communicated, and how quickly and efficiently the information may be processed, stored, or communicated. The variations in information handling systems allow for information handling systems to be general or configured for a specific user or specific use such as financial transaction processing, airline reservations, enterprise data storage, or global communications. In addition, information handling systems may include a variety of hardware and software components that may be configured to process, store, and communicate information and may include one or more computer systems, data storage systems, and networking systems.
Many paradigms exist for designing firmware updates. Examples include platform “compatibility bits” used by updates. Another example is the practice of updating a device with monolithic binary images. These conventional firmware update practices do not always handle the network adapter (and other peripheral) product line complexities. Features are added and subtracted by suppliers over time and sometimes deployed across a product line with one firmware update package. However, the simplicity of this conventional practice for customers creates complexity for the implementers. This complexity is sometimes handled by operating system (OS)-based updates where vendor written logic corresponding to the update in progress can handle the changes and re-designs of the new package. However, this is not possible with pre-boot updates handled by device firmware loaded only from the existing firmware on a given device such as network adapter.
FIG. 1 illustrates an attempted conventional device pre-boot firmware update methodology for an information system 100 such as a server that includes a target PCIe device (in this case an Intel network adapter 106) that contains Version N of existing field-deployed unified extensible firmware interface (“UEFI”) driver firmware 120 such as Option ROM stored in non-volatile memory for use during system boot. As shown in FIG. 1, existing firmware image 122 also includes existing components A and B. Over time, Version N UEFI driver firmware 120 cannot handle newer payloads for adapter device 106. Therefore, Version N of existing field-deployed driver firmware 120 must be unloaded and replaced by an updated newer Version N+1 of driver firmware 108. However, as described below payloads associated with new driver version N+1 firmware 108 cannot be applied to adapter device 106 while it is running existing Version N driver firmware 120 due to forward compatibility problems.
A similar problem can occur with firmware updates to other information handling system devices, e.g., such as RAID controller, BIOS, complex programmable logic devices (CPLDs), and other Firmware Management Protocol (FMP) based devices of an information handling system 100. Moreover, driver firmware downgrades may not be possible for similar reasons, e.g. such as when a newly loaded Version N+1 of driver firmware may be released with problems, necessitating a firmware downgrade to an older firmware version such as Version N−1 of driver firmware which includes one or more payload components that cannot be applied to a device while it is running the existing Version N+1 driver firmware. These problems can result in product defects and lack of out-of-band firmware update capability.
For example, in FIG. 1 a staged or step firmware update package including Version N+1 device driver 108 is being retrieved by a remote access controller (RAC) 102 into its internal non-volatile storage (staged update storage partition) from a firmware source 150 such as attached Flash storage device, network server, etc. In this regard, remote access controller 102 may be an integrated Dell Remote Access Controller (iDRAC) executing lifecycle management logic (e.g., Dell Life Cycle Controller available from Dell Products L.P. of Round Rock, Tex.). As shown in FIG. 1, the staged firmware update 109 includes Version N+1 UEFI driver 108 for adapter 106, as well as firmware payload component A (actual firmware image that is to be used as input to SetImage function in the application programming interface that is defined by the UEFI standard in the firmware management protocol), new version firmware payload component B* (UEFI driver that is needed for the success of SetImage method to apply firmware image of component A), and new firmware payload component C, all for the same device adapter 106. As shown by the upward arrow in FIG. 1, the SetImage method uses the driver that is available. In this case version N 120 is present hence it is used, e.g. loaded into a UEFI Firmware module in system memory 104.
As further shown in FIG. 1, firmware update 109 including new Version N+1 UEFI driver firmware 108 is provided as a payload via RAC 102 to existing pre-boot software in the form of FMP-based pre-boot software (e.g., Dell Life Cycle Controller available from Dell Products L.P. of Round Rock, Tex.) 111 executing on host CPU 110 that operates to utilize FMP to update firmware for particular target devices on information handling system 100, e.g., in a manner consistent with Chapter 32 of UEFI Specification 2.4. FMP-based logic in turn attempts to provide the new firmware payload components of firmware update 109 to system random access memory (RAM) 104 via Firmware Management Protocol for loading to non-volatile memory of adapter 106. However, in the illustrated case, existing Version N of UEFI driver firmware 120 can only update Firmware images A and B*, while newer Version N+1 of UEFI Driver firmware 108 is required to update all Firmware images A, B* and C. Thus, new Version N+1 UEFI driver firmware 108 and the new payload components cannot be loaded into system memory 104 for use by adapter 106 for one or more possible reasons, e.g., new firmware payload component C is unrecognized by the existing version of FMP pre-boot software 111, etc. Since the payload components A, B* and C associated with new Version N+1 of driver firmware 108 cannot be applied to adapter 106 while it is running the existing Version N of UEFI driver firmware 120, then existing Version N of UEFI driver firmware 120 must be first unloaded prior to loading the newer Version N+1 of UEFI Driver firmware 108 to handle update A, B* and C firmware images.
FIG. 2 illustrates another conventional device firmware update methodology for an information system 100 that is provided by Chapter 32.2 of UEFI Specification 2.4. In this methodology, a UEFI capsule 300 as shown in FIG. 3 is provided with a capsule format that includes an EFI capsule header 302 and capsule body 304 that includes an EFI firmware management capsule header 318, an optional driver section 320 and a payload section 322. As shown, optional driver section 320 includes new driver firmware versions (e.g., such as new Version N+1 UEFI driver firmware 108) in the form of one or more optional drivers 328, together with one or more firmware payload components 330. Particular sections of EFI capsule header 302 include capsule identifier and size. Particular sections of EFI firmware management capsule header 318 include the number of payloads, drivers included along with the offsets at which they are available. Particular sections of each given optional firmware payload component 330 includes an EFI firmware management capsule image header 338, a binary update image section 339 and a vendor code bytes section 340, with the capsule image header 338 including an update image identifier that enables one to identify the appropriate driver required to apply the image as shown.
Using the methodology of FIG. 2, FMP pre-boot software 111 is supposed to locate and identify a new version of UEFI driver firmware (e.g., new Version of N+1 UEFI driver firmware 108) within UEFI capsule 300 as an optional component, and to then load it into non-volatile memory of adapter 106 or other target device via system memory 104 as shown if the new version 108 of driver firmware is found to be newer than the exiting version (e.g., existing Version N of UEFI driver firmware 120). In such a case, the existing version of driver firmware 120 is first unloaded as shown. However, existing deployments of FMP pre-boot software 111 are not capable of interpreting the new UEFI capsule format that includes the optional firmware driver 108 and payload sections 320 and 322. Further, no standardized logic to determine how and when to unload resident firmware drivers to be replaced have been detailed to date. In this regard, the sequence of Update to be applied is not specified. Additionally, using conventional methodology, drivers need to follow UEFI Driver Binding Protocol in the UEFI Capsule 300 (Get Driver Version) and only higher versions of driver firmware are loaded.